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BACKGROUND OF THE INVENTION 

1. Field of the Invention 

5 The present invention generally relates to the field of insurance claims. More 

particularly, the present invention relates to a system and method for externalization of 
rules for assessing bodily injury general damages. 

2. Description of the Related Art 

10 

Insurance companies have been processing and settling claims associated with 
bodily injury for a long time. The task of evaluating, analyzing or estimating the amount 
of damage associated with one or more types of bodily injuries, especially trauma- 
induced bodily injuries, can be very complex. Complexity in the evaluation process often 
15 arises out of the fact that concurrent expertise in legal, medical and insurance fields is 
often required to arrive at a particular decision involving a bodily injury claim. 

Several factors can affect the estimated amount of the claim associated with a 
bodily injury. Every accident is different and every injury is unique. Arriving at a 

20 customized evaluation of a bodily injury claim, which is unique for a specific accident, 
injury, etc. is desirable. Applying across-the-board standards may tend to result in an 
inequitable solution for one or more parties involved. External environmental factors, 
such as the experience level of a claims adjuster, record of accomplishment of the legal 
professionals, post-injury quality of life for the injured party, etc., all can affect the 

25 valuation of a claim. 

During the past several years, many insurance companies have been using 
computer-based and knowledge-based claim-processing systems to process, evaluate, 
analyze and estimate thousands of claims in a fair and consistent manner. A knowledge- 
30 based claim-processing system includes an expert system which utilizes and builds a 
knowledge base to assist the user in decision making. It may allow the insurance 
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companies to define new rules and/or use previously defined rules, in real-time. The 
business rules are generally written by industry experts to evaluate legal, medical, 
insurance conditions before arriving at a valuation of a claim. 

There were several drawbacks with the prior art knowledge-based system. For 
example, the business rules used in the prior art often lacked flexibility. The business 
rules were often hard-coded in the insurance claim processing software. Every time there 
was a new business requirement, it was necessary to change the source code. In some 
cases, this inflexibility resulted in delaying the incorporation of the new business rules 
until the next system release date. Thus the insurance claim processing software was 
unable to adapt quickly to changing business conditions. This reduced the users' and 
therefore the insurance companies' flexibility to respond to changing business conditions 
in assessing bodily injury claims. 

Very often, the user may have special or unique requirement, which may need the 
standard business rules to be modified (i.e., customized) to meet a specific application. 
The hard-coding method used in the prior art would not easily permit the customization 
of the business rules in a cost and time effective manner. 

It is, therefore, desirable to develop a new system and method for externalization 
of rules for assessing bodily injury general damages. It is desirable for the rules to be 
easily updateable based on external business conditions. It is also desirable for the rules 
to be customizable to meet specific user requirements. Thus, the new system and method 
for externalization of rules should be of a flexible design, to meet user requirements. 
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SUMMARY OF THE INVENTION 



The present invention provides various embodiments of a system and method for 
extemalization of rules to assess bodily injury general damages. In one embodiment, an 
5 insurance company may use an expert system to develop a knowledge base in the form of 
business rules to process insurance claims. A rules engine operable to execute the 
business rules may assist an insurance claims adjuster in assessing damages associated 
with bodily injury claims. 

10 The task of creation and maintenance of the business rules, used in the assessment 

of claims, may be automated by the extemalization of rules. In one embodiment, the 
database, which is external to the rules engine, may store all business rules, program 
n instructions, data, tables, objects, etc. associated with the processing of insurance claims. 
£ In one embodiment, the database may be an object oriented or a relational database. In 
O 15 one embodiment, the database may include a plurality of knowledge bases often stored in 
fT the form of tables. The user may create a rules data table, which is an embodiment of a 
=F knowledge base and which includes data necessary to transform the data to business 
= rules, based on a rule syntax structure specified in the template table. In one embodiment, 

a rule style or a rule syntax structure includes a premise and one or more resulting 
FU 20 actions. The entire set of business rules created to process insurance claims may be 
□ classified into a plurality of rule styles. In one embodiment, new rule styles may be 
u created and added to existing rule styles to customize the business rules. 

The transformation method, in one embodiment, orchestrates the combining of the 
25 data from the rules data table and the rule syntax structure specified in the template table 
and line text table. Each row of the rules data table may be read at a time. Data stored in 
each column of the rules data table may be used to transform or create the business rules. 
In one embodiment, entries for rules style may be used as a key to read a matching record 
in the template table. The matching record in the template table may specify the specific 
30 rule syntax structure. The new business rule may be saved in an associated knowledge 
base. 
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# 



By changing or modifying the data stored in the rules data table and using the 
transformation method it may be possible to update the business rules. Changing or 
adding new entries to the rules style may customize the business rules. 

5 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Figure la is a block diagram illustrating the architecture of one embodiment of an 
insurance claims processing system; 
5 Figure lb illustrates one embodiment of a networked insurance claim processing 

system; 

Figure 2 illustrates a flow chart to transform rules data to rules for assessing 
bodily injury damages claims according to one embodiment; 

Figure 3a illustrates data elements of a rules data table according to one 
10 embodiment; 

Figure 3b illustrates data elements of a template table according to one 
embodiment; 

Figure 3c illustrates data elements of a line text table according to one 
embodiment; and 

15 Figure 4 illustrates a block diagram of the transformation of rules data to rules for 

assessing bodily injury damages according to one embodiment. 

While the invention is susceptible to various modifications and alternative forms, 
specific embodiments thereof are shown by way of example in the drawings and will 

20 herein be described in detail. It should be understood, however, that the drawings and 
detailed description thereto are not intended to limit the invention to the particular form 
disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and 
alternatives falling within the spirit and scope of the present invention as defined by the 
appended claims. Note, the headings are for organizational purposes only and are not 

25 meant to be used to limit or interpret the description or claims. 
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DETAILED DESCRIPTION OF SEVERAL EMBODIMENTS 

Figure la: A block diagram illustrating the architecture of one embodiment of an 
insurance claims processing system 

5 

In Figure la, an embodiment of an insurance claims processing system 10 may 
include a computer system 20. The term "computer system" as used herein generally 
includes the hardware and software components that in combination allow the execution 
of computer programs. The computer programs may be implemented in software, 

10 hardware, or a combination of software and hardware. A computer system's hardware 
generally includes a processor, memory media, and Input/Output (I/O) devices. As used 
herein, the term "processor" generally describes the logic circuitry that responds to and 
processes the basic instructions that operate a computer system. The term "memory" is used 
synonymously with "memory medium" herein. The term "memory medium" is intended to 

15 include an installation medium, e.g., a CD-ROM, or floppy disks, a volatile computer 
system memory such as DRAM, SRAM, EDO RAM, Rambus RAM, etc., or a non-volatile 
memory such as optical storage or a magnetic medium, e.g., a hard drive. The memory 
medium may comprise other types of memory as well, or combinations thereof. In addition, 
the memory medium may be located in a first computer in which the programs are executed, 

20 or may be located in a second different computer which connects to the first computer over 
a network. In the latter instance, the second computer provides the program instructions 
to the first computer for execution. Also, the computer system may take various forms, 
including a personal computer system, mainframe computer system, workstation, 
network appliance, Internet appliance, personal digital assistant (PDA), television system 

25 or other device. In general, the term "computer system" can be broadly defined to 
encompass any device having a processor, which executes instructions from a memory 
medium. 

The memory medium preferably stores a software program or programs for 
30 processing insurance claims as described herein. The software program(s) may be 
implemented in any of various ways, including procedure-based techniques, component- 
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based techniques, and/or object-oriented techniques, among others. For example, the 
software programs may be implemented using a rule-based development tool such as 
PLATINUM Aion™ available from Computer Associates International, Inc. In one 
embodiment, PLATINUM Aion™ may combine business rule and object-oriented 

5 technologies to create and maintain complex, knowledge-intensive applications. 
Software developed with PLATINUM Aion™ may employ an Aion™ programming 
language for automation of processes which may use hundreds or thousands of business 
rules from a knowledge base. An Aion™ inference engine may automatically determine 
which rules to execute, when, and in what order. In various other embodiments, the 

10 software program may be implemented using other technologies, languages, or 
methodologies, as desired. A CPU, such as the host CPU, executing code and data from 
the memory medium includes a means for creating and executing the software program 
or programs according to the methods, flowcharts, and/or block diagrams described 
below. 



A computer system's software generally includes at least one operating system, a 
specialized software program that manages and provides services to other software 
programs on the computer system. Software may also include one or more programs to 
perform various tasks on the computer system and various forms of data to be used by the 
20 operating system or other programs on the computer system. The data may include but are 
not limited to databases, text files, and graphics files. A computer system's software 
generally is stored in non-volatile memory or on an installation medium. A program may be 
copied into a volatile memory when running on the computer system. Data may be read 
into volatile memory, as the data is required by a program. 



A server may be defined as a computer program that, when executed, provides 
services to other computer programs executing in the same or other computer systems. 
The computer system on which a server program is executing may also be referred to as a 
server, though it may contain a number of server and client programs. In the client/server 
30 model, a server is a program that awaits and fulfills requests from client programs in the 
same or other computer systems. 
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25 




The insurance claims processing system 10 may further include a display screen 
50 connected to the computer system 20 and an insurance database 40 residing on an 
internal or external storage. The database may also be referred to as a repository. As 

5 used herein, a "database" may include a collection of information from which a computer 
program may select a desired piece of data. As used herein, an "insurance database" is 
used as a synonym for a "database" when included in or coupled to an insurance claims 
processing system 10. System 20 includes memory 30 configured to store computer 
programs for execution on system 20, and a central processing unit (not shown) 

10 configured to execute instructions of computer programs residing on system 20. Claims 
processing program 60, also referred to as application program software 60, may be 
stored in memory 30. As used herein, an "insurance claims processing program" 60 may 
include a software program which is configured to conduct transactions regarding 



*Z The insurance claims processing system 10 may be used by an Insurance 

=p Company for various embodiments of a system and method for externalization of rules 
q for assessing bodily injury general damages associated with a bodily injury insurance 
J 1 claim. As used herein, an Insurance Company (IC) includes a business organization that 
y 20 provides insurance products and/or services to customers. More particularly, the 
« insurance products may pertain to providing insurance coverage for accidents and the 

trauma-induced bodily injuries that may result due to the accident. Examples of trauma- 
induced bodily injuries may include, but are not limited to: loss of limb(s); bone 
fractures; head, neck and/or spinal injury, etc. 



In one embodiment, on receiving a trauma-induced bodily injury, a customer may 
file an insurance claim with his/her insurance organization to cover medical and other 
accident-related expenses. An IC may utilize a computer-based insurance claim 
processing system to process insurance claims. In one embodiment, the processing may 
30 include estimating a financial value associated with the filed insurance claim. 



insurance claims, such as by estimating the value of the insurance claims, for example. 



id 15 



25 
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As used herein, an IC business transaction may be defined as a service of an IC. 
Examples of business transactions include, but are not limited to: insurance transactions 
such as filing of claims, payment of claims, application for insurance coverage, and 
customized benefits, etc. Business transactions may also include services related to 
5 customers, insurance providers, employers, insurance agents, investigators, etc. 

As used herein, an IC insurance claim processing includes a series of instructions 
executed by a computer system for processing an IC's business transactions. A claim 
processing system may include one or more processing tasks. A processing task may 

10 include a sequence of one or more processing steps or an ordered list or a structured list 
of one or more processing steps, associated with the business transaction to be processed 
by the claim processing system. In one embodiment, the sequence of steps may be fixed. 
In another embodiment the sequence of steps may be established dynamically, in real- 
time. In one embodiment, the sequence of one or more steps may include an initial step, a 

15 final step, one or more intermediary steps, etc. In one embodiment, an IC user may select 
steps to process an insurance claim in a sequential manner. In another embodiment, the 
IC user may select steps to process an insurance claim in a random or arbitrary manner. 
Examples of processing steps may include, but are not limited to: receiving an input 
from a user of the IC insurance claim processing system, reading a value from a database, 

20 updating a field in a database, displaying the results of a business transaction on a 
computer screen, etc. 

In one embodiment, the insurance claim processing system may execute rules in 
the form of program instructions in response to completion of certain steps, events, user 
25 inputs, etc. and as part of processing of the insurance claim. The execution of the rules 
may result in certain actions such as selection of the next step, performing calculations, 
generating an error message, waiting for user input, etc. The specific number or type of 
rules executed will vary depending on the type of injuries, the type of treatments, etc. 
specified in the bodily injury damages claim. 
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In one embodiment, the insurance claim processing system utilizes object- 
oriented technology to process insurance claims and assess bodily injury damages. In 
another embodiment, processing of insurance claims may utilize traditional programming 
languages and databases to achieve the same result. Insurance objects may be defined to 
represent or model real-world business features of insurance products and services. 
Examples of insurance objects may include, but are not limited to, objects representing the 
following: an insurance claim; an accident report; a settlement; an estimated claim; IC 
service facilities, customers, and employees; business process such as a new insurance 
application and calculation of a premium; interfaces to external insurance organizations; 
work tasks such as calculations, decisions, and assignments; temporal objects such as 
calendars, schedulers, and timers; and elemental data necessary to accomplish work tasks 
such as medical costs, risk factors, etc. 

An insurance object may be represented on the computer screen by a graphical icon 
or by a display listing the properties of the insurance object in graphic and alphanumeric 
format. An insurance claim object may be configured to gather and evaluate data for 
processing a filed insurance claim and to automatically make decisions about the insurance 
claim. The one or more processing steps associated with the processing of an insurance 
claim may also be configured as one or more processing step objects. In one embodiment, a 
display screen may be associated with a processing step. The display screen may also be 
represented as an object. Each display screen object may include a property to point to a 
previous display and another property to point to a next display screen. Each property, e.g. 
the next display pointer on a display screen object, may be changed dynamically by using 
methods associated with the display screen object. One display screen object may serve as 
the starting point for processing insurance claims. In one embodiment, the starting point for 
processing insurance claims may include acquiring an insurance claim identification number 
from an IC system user. 

In one embodiment, during the processing of an insurance claim, a business rule 
and/or an IC system user input may determine that the insurance claim processing needs the 
execution of additional steps or tasks to continue the processing of the claim. The IC system 
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user may provide inputs to the insurance claims processing program 60 at any display screen 
associated with a step. The insurance claim processing software may dynamically modify 
the number of steps and/or the sequence of their execution to complete the claim processing 
transaction. An IC system user working at a client system may then iterate through the claim 
5 processing steps and assess a bodily injury damages associated with the insurance claim. 

In one embodiment, upon startup, the program 60 may provide a graphical user 
interface to display claims processing related information on display screen 50. It may 
collect user inputs, entered by using user input devices 52, and associated with insurance 

10 claims. It may process the user inputs, access an insurance database 40, use the contents 
of the insurance database 40 to estimate the insurance claim, and store it in memory 30 
and/or insurance database 40. The program 60 may display a value of the estimated 
insurance claim on display screen 50. A user may view the display of the estimated 
insurance claim on display screen 50, and may interactively make modifications, 

15 additions, and deletions to the estimated insurance claim. 

System 20 may also include one or more user input devices 52, such as a 
keyboard, for entering data and commands into the insurance claim program 60. It may 
also include one or more cursor control devices 54 such as a mouse for using a cursor to 
20 modify an insurance claim viewed on display screen 50. In response to the updating of 
the estimated insurance claim, the insurance claim program 60 may store the updated 
insurance claim in the insurance database 40. 

Figure lb: One embodiment of a networked insurance claim processing system 

25 

Figure lb illustrates one embodiment of a networked system, configured for 
processing insurance claims. In this embodiment, the system is shown as a client/server 
system with the server systems and client systems connected by a network 62. Network 
62 may be a local area network or wide area network, and may include communications 
30 links including, but not limited to: Ethernet, token ring, Internet, satellite, and modem. 
Insurance claims processing system 10 as illustrated in Figure la may be connected to 
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network 62. The insurance claims processing system software and insurance database 40 
may be distributed among the one or more servers 70 to provide a distributed processing 
system for insurance claim transactions. In other words, an insurance claim processing 
transaction being processed by the insurance claim processing system may be routed to 
5 any server based upon the workload distribution among servers 70 at the time of the 
transaction. Insurance claim processing system servers 70 may be located on a local area 
network or may be geographically dispersed in a wide area network. 

One or more client systems 80 may also be connected to network 62. Client 
10 systems 80 may reside at one or more claim processing units within the insurance 
company. In a wide area network, client systems 80 may be geographically dispersed. 
Client systems 80 may be used to access insurance claim processing system servers 70 
and insurance database 40. An insurance claim-processing employee may use a client 
system 80 to access the insurance claim processing system and execute insurance 
15 transactions. An employee may also use a client system 80 to enter insurance claim 
inputs into the insurance claim processing system. One or more printers 90 may also be 
connected to network 62 for printing documents associated with insurance claim 
transactions. 

20 Various embodiments further include receiving or storing instructions and/or data 

implemented in accordance with the description herein upon a carrier medium. Suitable 
carrier media include memory media or storage media such as magnetic or optical media, 
e.g., disk or CD-ROM, as well as transmission media or signals such as electrical, 
electromagnetic, or digital signals, conveyed via a communication medium such as 

25 networks and/or a wireless link. 

Figure 2: A flow chart to transform rules data to rules for assessing bodily injury 
damages claims according to one embodiment 



30 



Figure 2 illustrates one embodiment of a method to transform rules data to rules 
for assessing bodily injury damages claims according to one embodiment. In step 100, 
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the user or the administrator of the insurance claim processing system 20 provides a rules 
engine, which is capable of processing rules associated with assessing bodily injury 
damages claims. The rules engine may be included as part of the insurance claims 
processing system 10, such as the insurance claims processing program 60, as shown in 
5 Figure la. As used herein, a "rules engine" may include an expert system which is 
operable to produce an output as a function of a plurality of rules. A rules engine, in one 
embodiment, may include an expert computer system which utilizes and builds a 
knowledge base developed in the form of business rules and/or formulas to assist the user 
in decision-making. 

10 

It allows the insurance companies to capture the knowledge base of their experts 
by defining business rules. Once created, the expertise may be used in processing many 
transactions, including assessing bodily injury damages claims. The business rules enable 
claim-processing professionals to be assisted by industry experts to evaluate legal, 
15 medical, insurance conditions before arriving at a valuation of an insurance claim. In one 
embodiment, the rules engine may be developed using a commercial rule-based 
development tool such as PLATINUM Aion™, which is available from Computer 
Associates International, Inc. 

20 Business rules, often referred to simply as rules, are executable computer program 

instructions. The rules include computer commands or logical instructions to achieve a 
certain function. For example, rules may guide an assessment or estimate of bodily 
injury general damages. Each rule, in one embodiment, includes a premise followed by 
one or more resulting actions. For example, in one embodiment, a business rule may state 

25 'If patient requires hospitalization after emergency care treatment then the trauma 
severity level should be classified as major'. In this case, the premise is 'patient requires 
hospitalization after emergency care treatment'. The resulting action is 'trauma severity 
level should be classified as major'. In one embodiment, the insurance claim processing 
system may include several thousand business rules. The rules may be executed or fired, 

30 under the control of the insurance claim processing software, based on certain events, 
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user inputs, etc. Only pertinent rules, i.e., a subset of all the available rules, are typically 
selected and executed for processing a specific bodily injury damages claim. 

In step 110, the user or the administrator of the insurance claim processing system 
5 20 provides a database 40, which is external to the rules engine, and is capable of storing 
and/or retrieving information associated with insurance claim processing. As used herein, 
the term "external" means that the database is separate from the rules engine. The type of 
information stored and/or retrieved may include, but not be limited to, business objects, 
tables, rules, software source code, executable software, etc. In one embodiment, the 
10 database may be relational. In another embodiment, the database 40 may be an object- 
oriented database. 

In one embodiment, the database 40 may include a plurality of tables, often 
referred to as knowledge-bases, which may be accessed by an translator program or other 

15 application program to transform or create or generate the data stored in the tables into 
rules. In another embodiment, the application program may transform data stored in 
tables into static instances of an object class. In one embodiment, for example, the rules 
data table as shown by way of example in Figure 3a includes data structured in a tabular 
format, i.e., a table with several rows and columns. The rules data table includes all the 

20 relevant information necessary to transform each row of the rules data table into an 
equivalent business rule. 

The entire set of business rules may be grouped or classified into a plurality of 
rule styles. Each rule style may have a common construction style, i.e., the syntax for the 

25 rule premise and the resulting rule action may be common. In one embodiment, there 
may be several hundred pre-defined rules styles. New rule styles to meet user 
requirement may also be created and added to the existing rule style list or table. Data 
included in the rules data table shown in Figure 3a may typically include information 
necessary to construct the rule premise and the resulting one or more rule actions. In one 

30 embodiment, the rules data table shown in Figure 3a may include, but not be limited to, 
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columns such as an injury code 300, an adjustment type, an adjustment amount 310, a 
rule style 330, a rule name 320, etc. 

Other types of tables stored in the database 40, in one embodiment, may include a 
5 LineText table as shown by way of example in Figure 3c and a Template table as shown 
by way of example in Figure 3b. The LineText table may store lines or other elements of 
text which may be used to generate the rules. The Template table may include 
information which may be used by the application program to read each row of data from 
the rules data table and transform, create or generate the rules data into a rule. In one 
10 embodiment, every rule style may have an entry in the Template table. The location to 
store the transformed rule, the name of the rules data table, the name of the rule style, an 
identifier for the line text, etc. may also be included in the Template table, in one 
embodiment. 

15 In step 130 of Figure 2, the application program initiates the transformation of 

data stored in the rules data table to rules by reading the rules data. In one embodiment, 
the KBOpen and the ControlLoad methods may be used to open and load the rules data 
knowledge base table. In one embodiment, every knowledge base table has a 
corresponding object class name in the insurance claim-processing program 60. The 

20 contents of each row are read one at a time. 

In step 140, data entries in each column of the rules data table are used to 
transform, create, or construct the rules. Entries for columns like rules style and rules 
name in the rules data table may be used as a key to find a matching record in the 
25 Template table. Other data stored in the columns of the rules data may be used to build 
the rule premise and/or the resulting one or more rules action. 

The specific syntax used to construct the rule is specified in the Template for a 
given rule style 330 and a rule name 320. For example, in one embodiment, rule style 
30 RS000 and rule name RN000 may specify: 

IFMATCH Col#l WITH Col#2 = Col#3 THEN Col#4 = Col#5 
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where Col#l through Col#5 entries may be read from data stored in columns 1 through 5 
of the rules data table shown in Figure 3a and where rule style = RS000 and rule name = 
RN000. The text string corresponding to the above transformed rule may be stored in the 
Line_Text 370 field of the LineText table shown in Figure 3c using Line_TextED 360 as 
5 a location reference obtained from the Template table shown in Figure 3b. 

Although not explicitly shown, Steps 130 and 140 may be repeated, in one 
embodiment, to read all rows of the rules data knowledge base table and transform the 
data to a plurality of rules. On execution of the plurality of rules, applicable to a specific 
10 bodily injury claim consultation transaction, the insurance claim processing software 60 
may print a consultation report, which summarizes an assessment for the bodily injuries 
claim. 

In one embodiment, the task of updating, modifying or revising of rules may be 
15 simplified. To update a business rule, the user or the administrator of the insurance claim 
processing system 20 may update the data entries stored in the rules data table. By 
executing steps 130 and 140, the rules may be automatically updated to reflect the 
changes. 

20 In another embodiment, the task of customizing of rules to meet specific user 

requirements may also be simplified. To add a new business rule or structurally modify 
an existing rule, the user or the administrator of the insurance claim processing system 20 
may add a new entry to the rule style and rule name table and update the database 40. By 
executing steps 130 and 140, the rules may be automatically customized to reflect the 

25 new changes. 

Figures 3a, 3b and 3c: Rules data Table, Template Table and Line Text Table in one 
embodiment 



30 



Figures 3a, 3b and 3c illustrate the tabular structure of the Rules data Table, 
Template Table and Line Text Table according to one embodiment. Only four columns 
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are illustrated for each of the table. In one embodiment, each of the tables may comprise 
more or fewer columns. In one embodiment, the tables may be implemented in any 
number of ways, such as a relational database, in a variety of commercially available 
database management systems. The tables may have as many rows as may be supported 
5 by the database management system in which they are implemented. The tables may be 
accessed (e.g., searched, written to, read from, etc.) through a programming interface or 
standard access mechanism (e.g., SQL) which is supported by the database management 
system in which the tables are implemented. The data shown in the various tables in 
Figures 3a, 3b, and 3c are for purposes of example only and are not intended to be 
10 limiting. 

Figure 4: A block diagram of the transformation of rules data to rules for assessing bodily 
D injury damages according to one embodiment 

y i 

rf 15 In Figure 4, an embodiment of the transformation of rules data to rules may 

M include a knowledge table 400. In one embodiment, the knowledge table may be a rules 

jb data table as shown in Figure 3a. In one embodiment, the knowledge table 400 includes 

!l data necessary to transform, or build, or create, or define, or generate rules based on a 

m specified rule structure. The transformation method 420 (as discussed in greater detail 

j!] 20 with reference to Figure 2) orchestrates the combining of the data from the knowledge 
D table 400 and the rule syntax specified in the Template table 440. The transformation 

~~ method 420 may save the rule as text in an associated knowledge base or insurance 

database. 

25 Although the system and method of the present invention have been described in 

connection with several embodiments, the invention is not intended to be limited to the 
specific forms set forth herein, but on the contrary, it is intended to cover such 
alternatives, modifications, and equivalents as can be reasonably included within the 
spirit and scope of the invention as defined by the appended claims. 
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